General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

We have an application which is written in Swift, which activates Transparent Proxy network extension. Our Transparent Proxy module is a system extension, which is exposing an app proxy provider interface (We are using NETransparentProxyProvider class and in extension’s Info.plist we use com.apple.networkextension.app-proxy key.) Sometimes we have observed that on starting the transparent proxy extension, the startProxy overridden delegate method(override func startProxy(options: [String : Any]?, completionHandler: @escaping (Error?) -> Void) {) in our AppProxyProvider class which is derived from NETransparentProxyProvider being called more than once for the same extension(pid). This leads to Over-resume of an object crash as we invoke setTunnelNetworkSettings inside the startProxy delegate. As this is controlled by the system, we are not sure why this delegate being called more than once sometimes even if we call the start TransparentProxy only once. Note that, this issue is seen only in Mac OS Tahoe. Apple Feedback ticket: FB21464147 (startProxy delegate for NETransparentProxyProvider class is being called twice for the same pid extension sometimes)

I previously asked in the Network Extension forum about the supported architecture for local, user-controlled domain blocking on unmanaged consumer iPhones. Apple Developer Technical Support explained that using NEPacketTunnelProvider for a purpose other than a VPN is not a DTS-supported use case. DTS also noted that App Review has the final say regarding what may or may not be distributed through the App Store and directed me to App Review for clarification. URL Filters do not provide the intended device-wide domain visibility and user-controlled blocking. At the same time, the deployment restrictions described in TN3134 prevent the use of the relevant content-filtering provider types on unmanaged consumer iPhones. The proposed app is a consumer privacy and security app. It would use NEPacketTunnelProvider to identify destination domains locally and allow the user to block selected domains. The app would not provide a remote VPN service. Network traffic would not be routed to a remote VPN endpoint, and the app would not offer location changing, anonymous browsing, IP address masking, or access to a private network. My questions are: Would this use of NEPacketTunnelProvider be eligible for distribution on the App Store, even though DTS does not support this packet tunnel use case? Would App Review classify this as a VPN service, or could it be classified as a security or content-blocking app under App Store Review Guideline 5.4? If it is classified as a security or content-blocking app rather than a VPN service, may it be submitted by an individual Apple Developer Program member, or is enrollment as an organization required? I understand that a forum response cannot guarantee approval of a future submission. I am trying to clarify the likely classification and account requirement before proceeding with further development.

I am planning an iOS security and content-blocking app for unmanaged consumer iPhones. The app would not provide a traditional VPN service. It would not offer: Remote VPN servers Geographic location switching Access to a private corporate network IP-address masking as a service Anonymous browsing Instead, the app would allow the user to: View destination domains contacted by the device Classify destinations such as trackers, advertising, analytics, or potentially malicious domains Manually block selected domains Keep connection history and filtering decisions on the device I understand that NEFilterDataProvider and NEFilterControlProvider are the APIs intended for network content filtering. However, according to TN3134, these providers are not generally deployable for an unmanaged adult consumer iPhone. I also understand that TN3120 says NEPacketTunnelProvider should not be used as a general-purpose local content filter. This appears to leave a gap for an unmanaged consumer security app whose core feature is user-controlled, system-wide domain blocking. I am considering whether NETunnelProviderManager with an NEPacketTunnelProvider could support the feature, but I do not want to use the packet-tunnel API outside its supported purpose. My questions are: Is there currently a supported Network Extension architecture for system-wide, user-controlled domain blocking on an unmanaged adult consumer iPhone? Can an app with this purpose use NEPacketTunnelProvider, or would that necessarily be considered the unsupported general-purpose filtering use described in TN3120? If such an architecture is supported, could an app with this purpose be treated as an approved security or content-blocking provider under Guideline 5.4 rather than as an app offering a traditional VPN service? App Review Guideline 5.4 states that apps offering VPN services must be submitted by developers enrolled as organizations. It also states that parental-control, content-blocking, and security apps from approved providers may use NEVPNManager. For an app that does not provide a remote VPN service but uses Apple’s VPN configuration infrastructure only for local security and user-controlled blocking, must the developer still enroll as an organization, or may an individual Apple Developer Program member submit it?

Dear Apple: 1、We want to create a socket application using the C language interface on the WiFi Aware channel, utilizing native socket APIs such as socket, connect, bind, etc., to transmit data through the established WiFi Aware channel. However, we wrote a demo and tested it. On the iOS side, when initiating a socket connect, we received error code 65. We also used the IPv6 protocol. We would like to ask for help: Is it impossible to use native socket APIs for programming on the WiFi Aware channel? 2、If native sockets are not available, which interfaces are recommended for WiFi Aware communication on iOS? Thanks.

Hello! Users of my app observed behaviour that some apps stopped working after update to 15.7.8 via Beta channel with transparent proxy network extension on. The app receives Protocol not available error, and I see setsockopt SO_FLOW_DIVERT_TOKEN failed [42: Protocol not available] error in Console. To reproduce, create two rules in basic NETransparentProxyProvider: [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolTCP], [[NENetworkRule alloc] initWithDestinationNetwork:nil prefix:0 protocol:NENetworkRuleProtocolUDP], You may even return NO in handleNewFlow, it does not matter. After that, Safari won't open some sites, and Weather app will work unreliably. Do anyone knows any workaround for this problem? I've also create a relevant FB23788740.

Version: MacOS 12.1 When I was using NETransparentProxyProvider, I overrive handleNewFlow, handleNewUDPFlow , and return true for some process, and then call - (void)openWithLocalEndpoint:(NWHostEndpoint *)localEndpoint completionHandler:(void (^)(NSError *error))completionHandler; at the beginning, work fine, buy sometime, when I visited qiye.163.com website, I often got an error when I do code below: - (void)writeData:(NSData *)data withCompletionHandler:(void (^)(NSError *error))completionHandler; Error Domain=NEAppProxyFlowErrorDomain Code=1 "The operation could not be completed because the flow is not connected" UserInfo={NSLocalizedDescription=The operation could not be completed because the flow is not connected , and the whole computer could not access the Internet , handleNewFlow and handleNewUDPFlow both are no longer called, unless I turn off the VPN. Turn off VPN and then Internet can be access

We are using a Content Filter Network Extension to perform telemetry over the network activity of enterprise iOS devices. The filter itself is not blocking any connection. We encountered an issue where our Content Filter got stuck in a deadlock in the startFilter method of the NEFilterControlProvider. This resulted in a crash report where we see 64 threads stuck in the startFilter call. While the content filter was stuck in a deadlock, the device network connectivity was lost. We solved the deadlock issue coming from our logger, however, we would like to get a better understanding on the following points: What are the critical paths where a Content Filter can have a device wide impact on network connectivity? What is the behavior of the OS when the Content Filter is unresponsive (e.g. in startFilter, handle(Report), handleNewFlow)? Will it try to start the filter again? Force kill it ? We saw that startFilter was called multiple times in our crash reports whereas we expected it to be called only on vendor configuration changes. What is the lifecycle of the filter control provider and filter data provider ? When are the different methods like startFilter called ? We would like our Content Filter to never cause disruptions and implement a circuit breaker behavior in case any issue occurs. Do you have any recommendation on how to achieve this ?

Has anyone successfully requested an OHTTP Relay for URL filtering and got it approved? I first applied for a relay about a month ago, and it was rejected in the first 24h, apparently the DNS TXT record doesn’t have to be setup at the apex domain but at the PIR subdomain (or at least that’s my assumption because Apple doesn’t tell you). After correction the issue and resubmitting the request I haven’t heard back, it’s been in review for many weeks already. Has anyone experienced this kind of delay or has anyone gotten the relay approved?

Hi all, I've run into a kernel deadlock issue involving content filter + VPN system/network extension on macOS 26, and would really appreciate any insights. A user reported that their mac is occasionally assigened a 169.254.0.0/16 address and can't reach any website after connecting Wi-Fi. Disabling our content filter restores network connectivity immediately. They're running the following software on the mac: macOS 26 (issue reproduced on 25C56 and 25F71) NEFilterDataProvider-based content filter (our extension) VPN network extension A spindump taken while the system had lost network connectivity shows the content filter's process stuck while delivering an "allow" verdict to the kernel. All subsequent flow decisions for the extensions are blocked behind it, which would explain why new DHCP request can't complete and the interface stays on a self-assigned address. Based on the "last ran" and timestamp in the spindump, the underlying deadlock appears to have occurred while the computer wasn't connected to any Wi-Fi network, so there was no visible symptom at the time. The user only noticed something was wrong once they tried to reconnect and saw the bad IP address; they did not realize the content filter was already stuck. This issue may be identified by searching for keyword "sofreelastref" in the spindump (see comment below). Has anyone else seen a content filter + VPN hang like this on macOS 26? Any guidance or pointers would be greatly appreciated. Thanks in advance! For Developer Technical Support staffs: FB23720745 Shay

Hi, We are currently testing our Network Extension based solution on macOS 27 Beta and have observed some unexpected networking behavior. We would like to know whether other developers have encountered similar issues, or whether there are any known changes in macOS 27 Beta that may affect NEFilterDataProvider. Environment macOS 27 Beta (tested on multiple Beta versions) System Extension Network Extension NEFilterDataProvider (Content Filter) Xcode Beta Current Implementation Our product uses NEFilterDataProvider for network traffic filtering. To eliminate the possibility that our filtering logic is causing the issue, we created a minimal implementation. The current provider behavior: Only handles TCP 80/443 flows Does not inspect payload content Does not perform URL filtering Does not perform domain matching Does not apply any block rules Does not modify network traffic All flows are immediately allowed Example: handleNewFlow() | | return .allow() The issue can still be reproduced when all flows are returned with .allow(). The Network Extension is only performing basic flow handling without any filtering decisions. Observed Behavior On macOS 27 Beta, we can still reproduce networking issues with this minimal implementation. Observed symptoms include: Intermittent network connectivity issues DNS requests timing out or failing Some applications losing network access Chrome / Chromium-based applications are affected more frequently Safari sometimes continues working normally Disabling the Network Extension usually restores network connectivity Restarting or reloading the provider may require a significant amount of time before networking fully recovers The issue appears to be independent of filtering decisions, because: No traffic is blocked No complex policy evaluation is performed No packet modification is performed All flows are allowed Possible Areas Based on our investigation, we suspect this may be related to changes in: NEFilterDataProvider lifecycle handling Interaction between Network Extension and the system networking stack Network recovery behavior after provider restart/reload Possible changes in networking components such as NECP, networkd, or DNS handling Questions Has anyone observed similar behavior with NEFilterDataProvider on macOS 27 Beta? Are there any known compatibility considerations for Network Extension or Content Filter providers on macOS 27 Beta? Have there been any changes to Network Extension lifecycle management or networking behavior that developers should be aware of? Are there recommended debugging steps or diagnostic information that would help investigate this issue? We can provide additional information if needed: sysdiagnose Console logs Network Extension logs Sample project Feedback Assistant ID Thank you.

Since updating to macOS 27 beta 3 (build 26A5378j), my Mac is unable to establish any new TCP connections. This affects all outbound traffic regardless of destination or protocol, while ICMP (ping) continues to work normally. Steps to reproduce: Update to macOS 27 beta 3 (26A5378j) Connect to a standard home Wi-Fi network (no VPN, no proxy, no enterprise MDM profile) Attempt any outbound TCP connection (curl, git pull, ssh) Expected behavior: Connections to any HTTPS endpoint or SSH server should establish normally. Actual behavior: curl -4 -v https://github.com curl -4 -v https://google.com both hang indefinitely at "Trying [IP]..." — the TCP handshake never completes git pull over both HTTPS and SSH remotes times out with "Failed to connect... Timeout was reached" ping github.com and ping google.com both succeed normally and immediately This confirms the issue is isolated to TCP connection establishment, not DNS resolution or general network connectivity Issue persists identically across multiple reboots System info: macOS 27.0 beta 3, build 26A5378j Connected via personal home Wi-Fi (Bbox router) No VPN, no proxy, no enterprise security software Additional context: Multiple other users have reported identical symptoms on this same build across MacRumors forums and Reddit, describing broken connections in Firefox, Opera, Dropbox, Telegram, and Music/iTunes purchases, while Safari continues to work. Reported workarounds from other affected users include: Disabling "Limit IP Address Tracking" on the network interface Disabling all Network Extensions under System Settings → General → Login Items & Extensions Uninstalling CrowdStrike Falcon or similar EDR/security software (where present) This was working correctly on both beta 1 and beta 2, the regression appears to have been introduced specifically in beta 3.

Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

I’m building an iOS app that uses a Network Extension Content Filter provider. The app works when installed directly on a physical device from Xcode/development builds, but the same flow fails in TestFlight/App Store distribution builds. Main app bundle ID: com.project.betcontrolMain Network extension bundle ID: com.project.betcontrolMain.DNSFilterExtension Team ID: 74YN2U5NR9 The extension is embedded at: Runner.app/PlugIns/DNSFilterExtension.appex Both the containing app and extension are signed with: com.apple.developer.networking.networkextension = content-filter-provider The app also has Family Controls Distribution enabled. At runtime, enabling the content filter with NEFilterManager fails in TestFlight with: NEFilterErrorDomain code 5 - permission denied The same code path works when installed locally from Xcode. The code roughly does: NEFilterManager.shared().loadFromPreferences { error in let manager = NEFilterManager.shared() let providerConfiguration = NEFilterProviderConfiguration() providerConfiguration.filterBrowsers = true providerConfiguration.filterSockets = true providerConfiguration.vendorConfiguration = [:] manager.localizedDescription = "BetControl Website Shield" manager.providerConfiguration

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!

We are using the NEHotspotConfigurationManager to programmatically connect to a specific Wi-Fi network for a limited period of time. From iOS 26, this now triggers a Passwords prompt asking the user if they want to save the Wi-Fi settings in the Passwords app. There are two problems with this:- We are temporarily connecting for a specific purpose and this network is not intended for the user to connect to again The prompt even appears if the credentials are incorrect and the Wi-Fi network cannot be joined While I can see some benefit to this dialog for a user connecting to a new network, it should not be displayed when programmatically connecting, or at least there should be the ability to disable it. Secondly, it seems like an obvious bug that the dialog is shown before the Wi-Fi connection successfully connects - why offer the user to store invalid credentials?

We are developing a DLP agent that uses a NETransparentProxyProvider to perform traffic inspection and modification. Our architecture currently includes: LaunchAgent, which monitors user session activity (login/logout, session activation) Container App, which: installs and activates a System Extension creates and saves the NETransparentProxyManager configuration starts the transparent proxy via startVPNTunnel. We would like to automate the startup of the Transparent Proxy for all users, including newly created users, in a way that is fully supported by macOS. We are looking for official guidance on the correct and supported mechanism for starting a user‑level Network Extension (specifically NETransparentProxyProvider) automatically at user login. Questions: What is the recommended and supported way to automatically start a NETransparentProxyProvider at user login? Are there any constraints or best practices we should follow when designing an automatic startup flow for a Network Extension such as NETransparentProxyProvider? We would appreciate official clarification on the supported deployment patterns for starting a user‑level Transparent Proxy Network Extension automatically in multi‑user enterprise environments.

We got a feedback from apple side for our new request PIR server responded, but the canary value is not in the dataset. "www.apple.com/url-filter-test" should be set to 1 So we have validated this using our iOS app pointing to same environment and it is blocking this URL as per expectation as well as we have validated this using below curl docker exec pir-server sh -lc 'grep -n "www.apple.com/url-filter-test" /pir/data/input.txtpb; ls -l /pir/data/input.txtpb /pir/data/url-0.bin /pir/data/url-0.params.txtpb'; curl -sS -i https://ohttp.protectuswebfilter.com/.well-known/private-token-issuer-directory | sed -n '1,40p' Please help us, how they are validating this entry is available or not

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

We are building a NETransparentProxyProvider system extension on macOS. The extension needs a certificate identity provisioned by MDM for cryptographic operations at runtime (signing and/or mTLS). We have hit a wall where a PKCS#12-delivered identity resolves correctly inside the extension but an ACME-delivered identity does not, and we want to understand whether this is a known limitation, a gap, or whether there is a supported path we are missing. We understand the implications of the data protection keychain on macOS but wonder if there is a carveout here that may not be documented well. We deploy the extension via MDM (profile traditionally but could be via DDM on macOS27). A VPN profile delivers an identity reference to the extension at runtime via PayloadCertificateUUID which surfaces an identity reference within protocolConfiguration.identityReference. When referencing a PKCS#12 identity (com.apple.security.pkcs12 payload): the identityReference is 196 bytes, beginning with the 4-byte prefix 73737569 (ASCII "ssui"). The reference is self-describing — it embeds the keychain path (/Library/Keychains/System.keychain), the certificate subject (in our case, "Delegate Test CA"), the team ID, and a 20-byte SHA-1 hash at the tail. This format carries everything the Security framework needs to locate the item. Full reference (our test, redacted to structure): 73737569 00000020 <uuid-bytes> 00000000000000000000000000000006 64626e6d 00000023 2f4c696272…53797374656d2e6b6579636861696e00 ← /Library/Keychains/System.keychain 6974656d 00000069 80001000… ← item data incl. DER subject … 00000014 48b494ae47d1b7b07ed8c77a681337a3af8e92a8 ← 20-byte SHA-1 hash When referencing a ACME identity (com.apple.security.acme payload, ECSECPrimeRandom P-384, SE-backed): the identityReference is 20 bytes, beginning with the 4-byte prefix 63657274 (ASCII "cert"). The remaining 16 bytes are opaque — they do not embed a keychain path, certificate subject, or any other locator. Full reference (our test): 63657274 a4c7e569737944b1 ad464dc3bb398f14 Searching for the SecIdentity The PKCS#12 reference resolves using SecItemCopyMatching with kSecValuePersistentRef set to the 196-byte reference and kSecMatchSearchList pointing at System.keychain succeeds immediately, returning a SecIdentity with both SecIdentityCopyCertificate and SecIdentityCopyPrivateKey succeeding - this is obviously expected for an exportable software key type. The ACME reference fails using every path that we tried to search/load it as a SecIdentity. Primarily: kSecValuePersistentRef with kSecUseDataProtectionKeychain: true (no explicit keychain): -25291 (errSecNoDefaultKeychain) kSecValuePersistentRef with an explicit kSecMatchSearchList pointing at System.keychain: -50 (errSecParam) — combining kSecValuePersistentRef with an explicit keychain search list is an invalid parameter combination for the compact cert-format reference. kSecMatchItemList with an explicit kSecMatchSearchList: -25300 (errSecItemNotFound) SecKeychainItemCopyFromPersistentReference (legacy API): -25300 (errSecItemNotFound) kSecValuePersistentRef with no keychain qualifier at all: -25291 (errSecNoDefaultKeychain) com.apple.managed.vpn.shared access group (which i know has had entitled use on iOS): -34018 (errSecMissingEntitlement) Next steps The cert-format kSecValuePersistentRef produced by an ACME identity cannot be resolved in a root daemon context using any API path we can find. The ssui-format reference from a PKCS#12 identity works. With macOS 27, com.apple.configuration.network.vpn.vpn-plugin DDM declarations accept an Authentication.IdentityAssetReference which can point at an ACME identity asset. Traditional VPN profiles also support PayloadCertificateUUID referencing an ACME payload. Both paths result in the extension receiving a cert-format reference that it cannot resolve. Is there a supported API to resolve a cert-format kSecValuePersistentRef in a daemon context without a default keychain? Or is this just the reality of the DPK on macOS where ACME/SE-backed identities are not usable from system extensions, and the IdentityAssetReference and PayloadCertificateUUID fields only work for PKCS#12 or SCEP identity types in this context? For completeness: we have also explored ManagedApp.framework and ManagedAppIdentitiesProvider as an alternative delivery path, and believe this is the better method, but that hits a separate issue where managedappsd fails to verify the code signature of a system extension caller (filed separately as feedback FB23484530). Similar to this, we need to understand if the ExtensionConfigs in ManagedApp.framework are for appex user space app extensions only, and don't extend to System Extensions.